Conventionally, various inter-task (inter-process) communications methods are known that execute communications (sending-receiving, exchanging, or handing-over) of a message including data between tasks controlled by an RTOS (Real Time Operating System). (For instance, refer to JP-A-2002-189606)
For instance, FIG. 4A shows a flowchart diagram explaining a message transmission processing within a task (or a sub-routine that is invoked by the task) of a sender that is to send a message. FIG. 4B shows a flowchart diagram explaining a data reception/utilization processing within a task (or a sub-routine that is invoked by the task) of a recipient that is to receive a message.
Here, a task of a sender (sender task) refers to TASK A, while a task of a recipient (recipient task) refers to TASK B. TASK B is activated by the RTOS based on the message to utilize the data within the message. TASK A has a priority A, while TASK B has a priority B. The priority A is defined as having a higher priority level than the priority B. The RTOS is designed to follow a scheduling where the RTOS activates the most highly prioritized task among the tasks that are queued in an activation wait queue (Ready Queue) where tasks are waiting for being activated.
For instance, when an occurrence of an event is detected within TASK A, a message communications processing takes place for causing a processing routine for the event within TASK B to process the data relating to the event. The message transmission processing within TASK A, as shown in FIG. 4A, includes two Steps 11, 12. At Step 11, data as a transmission target is queued (or stored) in a queue for TASK B being a recipient of the message. At Step 12, an activation request is then outputted for requesting the RTOS to activate the corresponding recipient TASK B.
Upon receiving the activation request, the RTOS queues, in an activation wait queue, identification information (task ID) for identifying the task that is requested to be activated. Suppose that no more task ID of a task having a higher priority than TASK B exists in the activation wait queue after completion of the processing of TASK A having the priority A. Here, the RTOS activates TASK B based on the task ID being queued in the activation wait queue to execute TASK B.
Within TASK B, the data reception/utilization processing takes place, as shown in FIG. 4B. In detail, at Step 21, the data is retrieved from the queue for its own task, namely, the queue for TASK B. At Step 22, the processing using the retrieved data then takes place. In this way, a given processing within TASK A causes TASK B to be activated to execute a certain processing within TASK B itself. The certain processing within TASK B then retrieves (or receives) and utilizes the data queued by the certain processing within TASK A. For instance, necessary data for a certain event detected within TASK A is transferred and utilized in a processing routine for the certain event within TASK B.
In the above-mentioned conventional inter-task communications method, when a message is sent within TASK A multiple times from TASK A to TASK B having a lower priority level than TASK A, the message transmission processing is repeated multiple times, as shown in FIG. 4A. Further, suppose that each of the messages sent multiple times includes an individual data item.
Therefore, the data items corresponding to the respective messages sent multiple times are queued in a queue for TASK B, while an activation request for requesting for activating TASK B is queued multiple times in an activation wait queue (Ready Queue) of the RTOS. Thereafter, when no more task (or processing, interruption) having a higher priority than TASK B exists, a series of processings for delivering messages repeats to takes place multiple times. This series of processings includes the following: (1) Activation processing for activating TASK B by RTOS; (2) Data reception processing within TASK B (Step 21); (3) Data utilization processing using the received data within TASK B (Step 22); and (4) Termination processing for terminating TASK B.
For instance, FIG. 5 explains a processing flow of a message communications between tasks. Here, the routine for all of the processing shown in FIG. 4A refers to SEND MESSAGE FUNCTION, while the routine for the processing only at Step 21 shown in FIG. 4B refers to RECEIVE MESSAGE FUNCTION. Both the functions are included as sub-routines in an event service. Via the event service, three messages having Data A, Data B, and Data C, respectively, are sent from TASK A to the event processing routine within TASK B to cause the event processing routine within TASK B to perform based on Data A, Data B, and Data C. This event service can be provided as a portion within the RTOS, or a portion (sub-routine) within the respective tasks. In addition, the processing by the event service is assumed to be performed with the same priority level as an originating party that invokes the event service.
As shown in FIG. 5, as SEND MESSAGE FUNCTION of the event service is invoked within TASK A, Data A is transferred as an argument, to the event service. The event service then queues, within this SEND MESSAGE FUNCTION, Data A in the queue for TASK B, which corresponds to Step 11 in FIG. 4A. The event service then outputs an activation request for activating TASK B to the RTOS, which corresponds to Step 12 in FIG. 4A. Based on this activation request, the RTOS queues the task ID of TASK B in the activation wait queue. Further, TASK A transfers Data B to the event service by repeating to invoke SEND MESSAGE FUNCTION. The service then queues Data B in the queue for TASK B (Step 11) to output an activation request for TASK B to the RTOS (Step 12). Based on this activation request, the RTOS queues the task ID of TASK B in the activation wait queue. Yet further, TASK A transfers Data C to the event service by repeating to invoke SEND MESSAGE FUNCTION. The service then queues Data C in the queue for TASK B (Step 11) to output an activation request for TASK B to the RTOS (Step 12). Based on this activation request, the RTOS queues the task ID of TASK B in the activation wait queue. When the entire processings of TASK A is terminated, the RTOS takes over the sequence.
The RTOS refers to the activation wait queue to activate a task corresponding to the task ID having the highest priority level within the queue. Namely, the RTOS activates the tasks corresponding to the task IDs within the activation wait queue in a descending order of a priority level, i.e., from the highest to the lowest priority level. Here, suppose that there are, in the activation wait queue, no more tasks whose task IDs have higher priority levels than that of TASK B. Since the task IDs of TASK B are queued in the activation wait queue, TASK B is thereby activated (the uppermost “SCHEDULE” in FIG. 5). Here, two task IDs of TASK B still remain in the queue. In the processing within TASK B activated, RECEIVE MESSAGE FUNCTION is invoked from the event service. The event service retrieves, as the processing of RECEIVE MESSAGE FUNCTION, Data A queued for TASK B, which corresponds to Step 21 in FIG. 4B. The event service then transfers Data A to TASK B. TASK B performs processing using Data A retrieved from the event service, which corresponds to Step 22 in FIG. 4B. As the entire other processings of TASK B are terminated, the RTOS takes over the sequence. The RTOS refers to the activation wait queue to activate tasks in the descending order of the priority level. Here, since two task IDs of TASK B are queued in the activation wait queue, TASK B is thereby activated. Here, the single task ID of TASK B still remains in the activation wait queue. In the processing within TASK B activated, RECEIVE MESSAGE FUNCTION is invoked from the event service. The event service retrieves Data B queued for TASK B (Step 21), to transfer Data B to TASK B. TASK B performs processing using Data B retrieved from the event service (Step 22). As the entire other processings of TASK B are terminated, the RTOS takes over sequence. The RTOS refers to the activation wait queue to activate tasks in the descending order of the priority level. Here, since the single task ID of TASK B is queued in the activation wait queue, TASK B is thereby activated, which vacates the activation wait queue. In the processing within TASK B activated, RECEIVE MESSAGE FUNCTION is invoked from the event service. The event service retrieves Data C queued for TASK B (Step 21) to transfer Data C to TASK B. TASK B performs processing using Data C retrieved from the event service (Step 22). As the entire other processings of TASK B are terminated, the RTOS takes over the sequence.
In the above, within the sender task (TASK A), a message is transmitted multiple times to the recipient task (TASK B) without returning the sequence to the RTOS. By contrast, within the recipient task of TASK B, a series of processings occurs every single message. This series of processings includes the activation/termination processing (processings in the RTOS [e.g., processing for SCHEDULEs in FIG. 5]) and processing (e.g., determining processing for transferring to the processing shown in FIG. 4B). This increases a processing load in the processing unit (e.g., CPU).